Methods and systems for recommending packages of domain names for registration

ABSTRACT

A system and method are presented for recommending packages of domain names. One or more computer servers receive a query including at least one keyword from a user. A business category associated with the user is identified and a first ranking of top level domain names for the business category is identified. A package of candidate domain names is generated containing a candidate domain name for each top level domain in the first ranking of top level domain names. The package of candidate domain names relevant to the query is displayed for selection and registration by the user.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of and claims priority toU.S. patent application Ser. No. 13/965,627 filed Aug. 13, 2013 andentitled “METHODS AND SYSTEMS FOR RECOMMENDING TOP LEVEL AND SECONDLEVEL DOMAINS” which is a continuation-in-part of and claims priority toU.S. patent application Ser. No. 13/956,878 filed Aug. 1, 2013 andentitled “METHODS AND SYSTEMS FOR RECOMMENDING TOP LEVEL DOMAINS.”

FIELD OF THE INVENTION

The present inventions generally relate to domain name registration and,more particularly, systems and methods for recommending top level,second level, nth level and/or sub domains based on a number of factorsrelevant to a user and/or a business associated with the user.

SUMMARY OF THE INVENTION

An example embodiment of a method includes receiving, by one or morecomputer servers via a communications network, a query including atleast one keyword and a desired language. The query is submitted by auser via a client device. The method includes executing, by the one ormore computer services, a language detection program against the queryto identify a first language having a highest probability of a number ofcandidate language of being a language in which the query is written,identifying, by the one or more computer servers, one or more keywordsin the query, and translating, by the one or more computer servers, theone or more keywords from the first language identified by the languagedetection program into the desired language to generate one or moretranslated keywords. The method includes generating, by the one or morecomputer servers, a listing of candidate domain names relevant to theone or more translated keywords, and enabling, by the one or morecomputer servers, the user to select one or more of the candidate domainnames for registration.

An embodiment of a method includes receiving, by one or more computerservers via a communications network, a query including at least onekeyword, the query being submitted by a user via a client device,identifying, by the one or more computer servers, a business categoryassociated with the user, and a accessing, by the one or more computerservers, a data base storing a plurality of top level domain namerankings to identify a first ranking of top level domain names for thebusiness category. The method includes generating, by the one or morecomputer servers, a listing of candidate domain names relevant to thequery, and displaying, by the one or more computer servers, the listingof candidate domain names relevant to the query for selection andregistration by the user. The listing of candidate domain names isordered according to the first ranking of top level domain names for thebusiness category.

An embodiment of a system includes one or more computer serverscommunicatively coupled to a communications network and configured toperform the steps of receiving via the communications network a queryincluding at least one keyword and a desired language, the query beingsubmitted by a user via a client device, executing a language detectionprogram against the query to identify a first language having a highestprobability of a number of candidate language of being a language inwhich the query is written, identifying one or more keywords in thequery, translating the one or more keywords from the first languageidentified by the language detection program into the desired languageto generate one or more translated keywords, generating a listing ofcandidate domain names relevant to the one or more translated keywords,and enabling the user to select one or more of the candidate domainnames for registration.

An embodiment of a method includes receiving, by one or more computerservers via a communications network, a query including at least onekeyword. The query is submitted by a user via a client device. Themethod includes identifying, by the one or more computer servers, abusiness category associated with the user, accessing, by the one ormore computer servers, a data base storing a plurality of top leveldomain name rankings to identify a first ranking of top level domainnames for the business category, and generating, by the one or morecomputer servers, a package of candidate domain names relevant to thequery. The package of candidate domain names including a candidatedomain name for each top level domain name in the first ranking of toplevel domain names. The method includes displaying, by the one or morecomputer servers, the package of candidate domain names relevant to thequery for selection and registration by the user.

An embodiment of a method includes receiving, by one or more computerservers via a communications network, a query including at least onekeyword. The query is submitted by a user via a client device. Themethod includes identifying, by the one or more computer servers, abusiness category associated with the user, identifying, by the one ormore computer servers, a first ranking of top level domain names for thebusiness category, and generating, by the one or more computer servers,a package of candidate domain names containing a candidate domain namefor each top level domain in the first ranking of top level domainnames. The method includes displaying, by the one or more computerservers, the package of candidate domain names relevant to the query forselection and registration by the user.

An embodiment of a system includes one or more computer serverscommunicatively coupled to a communications network and configured toperform the steps of receiving, by one or more computer servers via acommunications network, a query including at least one keyword, thequery being submitted by a user via a client device, identifying, by theone or more computer servers, a business category associated with theuser, accessing, by the one or more computer servers, a data basestoring a plurality of top level domain name rankings to identify afirst ranking of top level domain names for the business category,generating, by the one or more computer servers, a package of candidatedomain names relevant to the query, the package of candidate domainnames including a candidate domain name for each top level domain namein the first ranking of top level domain names, and displaying, by theone or more computer servers, the package of candidate domain namesrelevant to the query for selection and registration by the user.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating a possible embodiment of a methodfor recommending top level, second level, nth level and/or sub domains.

FIG. 2 illustrates a possible embodiment of a system for recommendingtop level, second level, nth level and/or sub domains.

FIG. 3 illustrates a more detailed possible embodiment of a system forrecommending top level, second level, nth level and/or sub domains.

FIG. 4 is a flow diagram illustrating a possible embodiment of a methodfor recommending top level, second level, nth level and/or sub domains.

FIG. 5 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains.

FIG. 6 is a flow diagram illustrating a possible embodiment of a methodfor recommending top level, second level, nth level and/or sub domains.

FIG. 7 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains.

FIG. 8 is a flow diagram illustrating a possible embodiment of a methodfor recommending top level, second level, nth level and/or sub domains.

FIG. 9 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains.

FIG. 10 is a flow diagram illustrating a possible embodiment of a methodfor recommending top level, second level, nth level and/or sub domains.

FIG. 11 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains.

FIG. 12 is a flow diagram illustrating a possible embodiment of a methodfor recommending top level, second level, nth level and/or sub domains.

FIG. 13 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains.

FIG. 14 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains where a user has entered search terms in a firstlanguage.

FIG. 15 is a flowchart depicting a method for generating candidatedomain names where the candidate domain names include TLDs rankedaccording to a preference table.

FIG. 16 is an example interface illustrating a possible embodiment of asystem and method for recommending top level, second level, nth leveland/or sub domains where the candidate domain names are ranked accordingto a preference table.

FIG. 17 is a flowchart illustrating a method for generating candidatedomain names where the candidate domain names include TLDs rankedaccording to a preference table that is delineated based upon businesstype and location.

FIG. 18 is a flowchart illustrating a method for recommending a packageof domain names for registration based at least in part upon a businesscategory or keyword.

FIGS. 19A and 19B are graphs illustrating example domain nameregistration maps.

FIG. 20 is a flowchart depicting a method for generating a candidatedomain name package.

FIG. 21 depicts an example user interface enabling a user to register acandidate domain name package after executing a search.

FIG. 22 is a flowchart illustrating an example method for filtering anumber of candidate domain names.

DETAILED DESCRIPTION

The present inventions will now be discussed in detail with regard tothe attached drawing figures, which were briefly described above. In thefollowing description, numerous specific details are set forthillustrating the Applicant's best mode for practicing the inventions andenabling one of ordinary skill in the art to make and use theinventions. It will be obvious, however, to one skilled in the art thatthe present inventions may be practiced without many of these specificdetails. In other instances, well-known machines, structures, and methodsteps have not been described in particular detail in order to avoidunnecessarily obscuring the present inventions. Unless otherwiseindicated, like parts and method steps are referred to with likereference numerals.

A network is a collection of links and nodes (e.g., multiple computersand/or other devices connected together) arranged so that informationmay be passed from one part of the network to another over multiplelinks and through various nodes. Examples of networks include theInternet, the public switched telephone network, the global Telexnetwork, computer networks (e.g., an intranet, an extranet, a local-areanetwork, or a wide-area network), wired networks, and wireless networks.

The Internet is a worldwide network of computers and computer networksarranged to allow the easy and robust exchange of information betweenpeople or organizations that make use of network or computer resources(users). Hundreds of millions of people around the world have access tocomputers connected to the Internet via Internet Service Providers(ISPs). Content providers (e.g., website owners or operators) placemultimedia information (e.g., text, graphics, audio, video, animation,and other forms of data) at specific locations on the Internet referredto as websites. Websites comprise a collection of connected or otherwiserelated, web pages. The combination of all the websites and theircorresponding web pages on the Internet is generally known as the WorldWide Web (WWW) or simply the Web.

Some Internet users, typically those that are larger and moresophisticated, may provide their own hardware, software, and connectionsto the Internet. But many Internet users either do not have theresources available or do not want to create and maintain theinfrastructure necessary to host their own websites. To assist suchindividuals (or entities), hosting companies exist that offer websitehosting services. These hosting providers typically provide thehardware, software, and electronic communication means necessary toconnect multiple websites to the Internet. A single hosting provider mayliterally host thousands of websites on one or more hosting servers.

Browsers are able to locate specific websites because each website,resource, and computer on the Internet has a unique Internet Protocol(IP) address. Presently, there are two standards for IP addresses. Theolder IP address standard, often called IP Version 4 (IPv4), is a 32-bitbinary number, which is typically shown in dotted decimal notation,where four 8-bit bytes are separated by a dot from each other (e.g.,64.202.167.32). The notation is used to improve human readability. Thenewer IP address standard, often called IP Version 6 (IPv6) or NextGeneration Internet Protocol (IPng), is a 128-bit binary number. Thestandard human readable notation for IPv6 addresses presents the addressas eight 16-bit hexadecimal words, each separated by a colon (e.g.,2EDC:BA98:0332:0000:CF8A:000C:2154:7313).

IP addresses, however, even in human readable notation, are difficultfor people to remember and use. A Uniform Resource Locator (URL) is mucheasier to remember and may be used to point to any computer, directory,or file on the Internet. A browser is able to access a website on theInternet through the use of a URL. The URL may include a HypertextTransfer Protocol (HTTP) request combined with the website's Internetaddress, also known as the website's domain name. An example of a URLwith a HTTP request and domain name is: http://www.companyname.com. Inthis example, the “http” identifies the URL as a HTTP request and the“companyname.com” is the domain name.

Domain names are much easier to remember and use than theircorresponding IP addresses. The Internet Corporation for Assigned Namesand Numbers (ICANN) approves some Generic Top-Level Domains (gTLD) anddelegates the responsibility to a particular organization (a “registry”)for maintaining an authoritative source for the registered domain nameswithin a TLD and their corresponding IP addresses. For certain TLDs(e.g., .biz, .info, .name, and .org) the registry is also theauthoritative source for contact information related to the domain nameand is referred to as a “thick” registry. For other TLDs (e.g., .com and.net) only the domain name, registrar identification, and name serverinformation is stored within the registry, and a registrar is theauthoritative source for the contact information related to the domainname. Such registries are referred to as “thin” registries. Most gTLDsare organized through a central domain name Shared Registration System(SRS) based on their TLD.

The process for registering a domain name with .com, .net, .org, andsome other TLDs (including recently-introduced customized gTLDs) allowsan Internet user to use an ICANN-accredited registrar to register theirdomain name. For example, if an Internet user, John Doe, wishes toregister the domain name “mycompany.com,” John Doe may initiallydetermine whether the desired domain name is available by contacting adomain name registrar. The Internet user may make this contact using theregistrar's webpage and typing the desired domain name into a field onthe registrar's webpage created for this purpose. Upon receiving therequest from the Internet user, the registrar may ascertain whether“mycompany.com” has already been registered by checking the SRS databaseassociated with the TLD of the domain name. The results of the searchthen may be displayed on the webpage to thereby notify the Internet userof the availability of the domain name. If the domain name is available,the Internet user may proceed with the registration process. If thedomain name is not available for registration, the Internet user maykeep selecting alternative domain names until an available domain nameis found.

Applicant has determined, however, that presently-existing methods andsystems only suggest available domain names based upon synonyms of thedesired domain name, and do not provide customized TLDs, second leveldomains (SLD), nth level domains and/or sub domains for the domain namebased upon a location and/or a preferred language of the user. Thus, ifa user cannot find a desired domain name specific to the user's languageand/or current location, the user may have to sacrifice the desireddomain name with a TLD, SLD, nth level domains and/or sub domainsspecific to the language or location for a completely different domainname based on nothing more than synonyms of the desired domain name or aTLD specified by the user.

Applicant has therefore determined that optimal systems and methods mayimprove on presently-existing domain name suggestion algorithms bydetermining the location and/or preferred language of the user andsuggesting the desired domain name(s), including a TLD, SLD, nth leveldomain and/or sub domain customized to the location and/or preferredlanguage. Optimally, these systems and methods may determine thelocation and/or preferred language of the user based upon: a useraccount for the user; a browser cookie stored on the client computer; abrowser setting for a browser running on the client computer; a URLentered into the browser; and/or an IP address of the client computer.Such systems and methods may overcome a lack of TLD, SLD, nth leveldomain and/or sub domain customization introduced by presently-existingmethods and systems.

Several different methods may be used to provide and manage thedisclosed inventions. In an example embodiment illustrated in FIG. 1,any combination of software modules running on one or more servercomputers, as described herein, may receive, from one or more clientcomputers communicatively coupled to the network, a request for one ormore domain names, the request possibly comprising a text string forrequesting the domain name (Step 100), and may request and receive adata comprising: i) a user account for a user operating the client; ii)a browser cookie stored on the client, possibly comprising datagenerated and stored during a previous session; iii) at least onebrowser setting for a browser running on the client; iv) a URL enteredinto the browser; and/or v) an IP address of the client on the network(Step 110).

The method illustrated in FIG. 1 may further comprise the steps of: theserver determining, from the data, i) a location of the client; and/orii) a preferred language for a user operating the client (Step 120);identifying, within a database communicatively coupled to the network, aTLD associated with the location and/or with the preferred language,and/or generating an SLD, nth level domain and/or sub domain associatedwith the location and/or with the preferred language; (Step 130) andgenerating and transmitting to the client, for display in the browser, apresentation of the generated domain name comprising the top leveldomain, the second level domain, the nth level domain and/or the subdomain (Step 140).

Several different environments may be used to accomplish the steps ofembodiments disclosed herein. FIG. 2 demonstrates a streamlined exampleof such an environment and illustrates a non-limiting example of asystem and/or structure that may be used to accomplish the methods andembodiments disclosed and described herein. Such methods may beperformed by any central processing unit (CPU) in any computing system,such as a microprocessor running on one or more servers 210 and/or oneor more clients 220, and executing instructions stored (perhaps asscripts and/or software, possibly as software modules) incomputer-readable media accessible to the CPU, such as a hard disk driveon a server(s) 210 and/or client(s) 220.

The example embodiments herein place no limitations on whom or what maycomprise users. Thus, as non-limiting examples, users may comprise anyindividual, entity, business, corporation, partnership, organization,governmental entity, and/or educational institution.

The example embodiments shown and described herein exist within theframework of a network 200 and should not limit possible networkconfiguration or connectivity. Such a network 200 may comprise, asnon-limiting examples, any combination of the Internet, the publicswitched telephone network, the global Telex network, computer networks(e.g., an intranet, an extranet, a local-area network, or a wide-areanetwork), a wired network, a wireless network, a telephone network, acorporate network backbone or any other combination of known or laterdeveloped networks.

At least one server 210 and at least one client 220 may becommunicatively coupled to the network 200 via any method of networkconnection known in the art or developed in the future including, butnot limited to wired, wireless, modem, dial-up, satellite, cable modem,Digital Subscriber Line (DSL), Asymmetric Digital Subscribers Line(ASDL), Virtual Private Network (VPN), Integrated Services DigitalNetwork (ISDN), X.25, Ethernet, token ring, Fiber Distributed DataInterface (FDDI), IP over Asynchronous Transfer Mode (ATM), InfraredData Association (IrDA), wireless, WAN technologies (T1, Frame Relay),Point-to-Point Protocol over Ethernet (PPPoE), and/or any combinationthereof.

The server(s) 210 and client(s) 220 (along with software modules and thedata storage 230 disclosed herein) may be communicatively coupled to thenetwork 200 and to each other in such a way as to allow the exchange ofinformation required to accomplish the method steps disclosed herein,including, but not limited to receiving the information from a userinterface on one or more clients 220, and one or more servers 210receiving the information as transmitted by the client(s) 220.

The client 220 may be any computer or program that provides services toother computers, programs, or users either in the same computer or overa computer network 200. As non-limiting examples, the client 220 may bean application, communication, mail, database, proxy, fax, file, media,web, peer-to-peer, or standalone computer, cell phone, “smart” phone,personal digital assistant (PDA), etc. which may contain an operatingsystem, a full file system, a plurality of other necessary utilities orapplications or any combination thereof on the client 220. Non limitingexample programming environments for client applications may includeJavaScript/AJAX (client side automation), ASP, JSP, Ruby on Rails,Python's Django, PHP, HTML pages or rich media like Flash, Flex,Silverlight, any programming environments for mobile “apps,” or anycombination thereof.

The client computer(s) 220 which may be operated by one or more usersand may be used to connect to the network 200 to accomplish theillustrated embodiments may include, but are not limited to, a desktopcomputer, a laptop computer, a hand held computer, a terminal, atelevision, a television set top box, a cellular phone, a wirelessphone, a wireless hand held device, a “smart” phone, an Internet accessdevice, a rich client, thin client, or any other client functional witha client/server computing architecture. Client software may be used forauthenticated remote access to one more hosting computers or servers,described below. These may be, but are not limited to being accessed bya remote desktop program and/or a web browser, as are known in the art.

The user interface displayed on the client(s) 220 or the server(s) 210may be any graphical, textual, scanned and/or auditory information acomputer program presents to the user, and the control sequences such askeystrokes, movements of the computer mouse, selections with a touchscreen, scanned information etc. used to control the program. Examplesof such interfaces include any known or later developed combination ofGraphical User Interfaces (GUI) or Web-based user interfaces as seen inand after FIG. 4, including Touch interfaces, Conversational InterfaceAgents, Live User Interfaces (LUI), Command line interfaces, Non-commanduser interfaces, Object-oriented User Interfaces (OOUI) or Voice userinterfaces. Any information generated by the user, or any otherinformation, may be accepted using any field, widget and/or control usedin such interfaces, including but not limited to a text-box, text field,button, hyper-link, list, drop-down list, check-box, radio button, datagrid, icon, graphical image, embedded link, etc.

The software modules used in the context of the current invention may bestored in the memory of—and run on—at least one server 210 and/or client220. The software modules may comprise software and/or scriptscontaining instructions that, when executed by a microprocessor on aserver 210 and/or client 220, cause the microprocessor to accomplish thepurpose of the module or the methods disclosed herein. The softwaremodules may also include mobile applications, possibly on a clientcomputer and/or mobile device. These mobile applications, or “apps” maycomprise computer software designed to help people perform an activityand designed to help the user to perform singular or multiple relatedspecific tasks. It may help to solve problems in the real world bymanipulating text, numbers, graphics, or a combination of theseelements.

The environment(s) in FIGS. 2-3 may include one or more centralizedsoftware modules capable of connecting to any type of software withinthe environment. In some embodiments, this centralized software maycomprise an Application Programming Interface (API) and any request tothe API disclosed herein may comprise a Remote Procedure Call (RPC) tothe API. An API may comprise a service made available to third parties,which may further comprise any individual, entity, system, hardware, orsoftware wishing to access the disclosed information and functionality.Such an API may comprise a software-to-software interface that specifiesthe protocol defining how independent computer programs interact orcommunicate with each other. It also may comprise a collection ofpre-configured building blocks allowing a third party to easilyconfigure their software for compatibility and/or extensibility. The APImay allow a requesting party's software to communicate and interact withthe software application and/or its provider—perhaps over anetwork—through a series of function calls (requests for services). Itmay comprise an interface provided by the software application and/orits provider to support function calls made of the software applicationby other computer programs.

The API may comprise any API type known in the art or developed in thefuture including, but not limited to, request-style, Berkeley Sockets,Transport Layer Interface (TLI), Representational State Transfer (REST),Simple Object Access Protocol (SOAP), RPCs, Standard Query Language(SQL), file transfer, message delivery, and/or any combination thereof.The API may comprise computer-readable code that, when executed, causesthe API to receive an RPC (i.e., function call) requesting informationservices. Responsive to receipt of the RPC, the API may perform theabove described processes, and transmit a request results to therequesting third party. To submit the request via an RPC to the API, theserver(s) 210 may require authentication with the API. Computers orservers may locate the API via an access protected URL mapped to theAPI, and may then use an API key configured to authenticate the one ormore computers or servers prior to accessing the API.

The server(s) utilized within the disclosed system 210 may comprise anycomputer or program that provides services to other computers, programs,or users either in the same computer or over a computer network 200. Asnon-limiting examples, the server 210 may comprise application,communication, mail, database, proxy, fax, file, media, web,peer-to-peer, standalone, software, or hardware servers (i.e., servercomputers) and may use any server format known in the art or developedin the future (possibly a shared hosting server, a virtual dedicatedhosting server, a dedicated hosting server, a cloud hosting solution, agrid hosting solution, or any combination thereof). The server(s) 210may exist within a server cluster, as illustrated. These clusters mayinclude a group of tightly coupled computers that work together so thatin many respects they can be viewed as though they are a singlecomputer. The components may be connected to each other through fastlocal area networks which may improve performance and/or availabilityover that provided by a single computer.

The server(s) 210 or software modules within the server(s) 210 mayreceive hypertext transfer protocol (HTTP) requests for files or otherdata stored on the server(s) 210 and may use server-side scriptinglanguages such as ASP, PHP, CGI/Perl, proprietary scriptingsoftware/modules/components etc. to render the files requested andrespond with the rendered files/pages to be displayed on the client(s)220.

The server(s) 210 or software modules within the server(s) 210 may usequery languages such as MSSQL or MySQL to retrieve the content from datastorage 230. Server-side scripting languages such as ASP, PHP, CGI/Perl,proprietary scripting software/modules/components etc. may be used toprocess the retrieved data. The retrieved data may be analyzed in orderto determine information recognized by the scripting language,information to be matched to those found in data storage, availabilityof requested information, comparisons to information displayed andinput/selected from the user interface or any other content retrievalwithin the method steps disclosed herein.

The server 210 and/or client 220 may be communicatively coupled to datastorage 230 to retrieve any information requested. The data storage 230may be any computer components, devices, and/or recording media that mayretain digital data used for computing for some interval of time. Thestorage may be capable of retaining stored content for any datarequested, on a single machine or in a cluster of computers over thenetwork 200, in separate memory areas of the same machine such asdifferent hard drives, or in separate partitions within the same harddrive, such as a database partition.

Non-limiting examples of the data storage 230 may include, but are notlimited to, a Network Area Storage, (“NAS”), which may be aself-contained file level computer data storage connected to andsupplying a computer network with file-based data storage services. Thestorage subsystem may also be a Storage Area Network (“SAN”—anarchitecture to attach remote computer storage devices to servers insuch a way that the devices appear as locally attached), an NAS-SANhybrid, any other means of central/shared storage now known or laterdeveloped or any combination thereof.

Structurally, the data storage 230 may comprise any collection of data.As non-limiting examples, the data storage 230 may comprise a localdatabase, online database, desktop database, server-side database,relational database, hierarchical database, network database, objectdatabase, object-relational database, associative database,concept-oriented database, entity-attribute-value database,multi-dimensional database, semi-structured database, star schemadatabase, XML database, file, collection of files, spreadsheet, and/orother means of data storage such as a magnetic media, hard drive, otherdisk drive, volatile memory (e.g., RAM), non-volatile memory (e.g., ROMor flash), and/or any combination thereof.

As seen in FIG. 2, the software modules, server(s) 210 and/or datastorage 230 may exist and/or be hosted in one or more data centers 240,250. These data centers 240, 250 may provide hosting services forwebsites, services or software relating to stored information, or anyrelated hosted website including, but not limited to hosting one or morecomputers or servers in a data center 240, 250 as well as providing thegeneral infrastructure necessary to offer hosting services to Internetusers including hardware, software, Internet web sites, hosting servers,and electronic communication means necessary to connect multiplecomputers and/or servers to the Internet or any other network 200.

As users access and/or input information, this information may beredirected and distributed between and among the data centers 240, 250via commands from any combination of software modules hosted on theserver(s) 210 and executed via processors on the server(s) 210. Thisinformation may then be accessed and manipulated by the combination ofsoftware modules or stored in the data storage 230 of any of a pluralityof data centers, either separate from or integrated into the one or moreservers, so that the information is available to be searched andaccessed by the user and/or any other components of any or all datacenters.

Any references to “software combination,” “combination of software,”“combination of software modules” etc. referred to herein may includeany combination of software modules executed by a microprocessor oneither the server 210 or client 220 computers. These software modulesmay also be used in combination with any other method steps, hardwareand/or software structures disclosed herein. The servers 210 may behosted in any data center 240, 250 operated by any hosting provider suchas those disclosed herein and the servers 210 and clients 220 may beoperated by any users disclosed herein.

In the interest of simplicity, FIG. 3 shows a consolidated environmentfor accomplishing the methods disclosed herein, where the components ofthe system are all hosted on a single server computer 210 in a singledata center 240, 250. Other embodiments, however, may utilize a highlydistributed environment wherein the various system components are eachhosted on their own separate server 210 and communicatively coupled toone another via the network 200. Thus, any combination of the disclosedsoftware may be hosted on any combination of server(s) 210 andcommunicatively coupled to the network 200.

As seen in FIG. 3, the server(s) 220 may host and run one or more useraccount software modules 300. These user account module(s) 300 may beconfigured to access an administrative account for a user of theservices provided by a business entity (e.g., GO DADDY'S MANAGE YOURACCOUNT administration software, as a non-limiting example). Thisaccount may also be known as a “user account,” “customer account” or“shopper account” for a user.

Non-limiting examples of the business entities that may provide theseservices may include a domain name registry, a domain name registrar, ahosting provider, a secure sockets layer (SSL) or other online securityCertification Authority (CA), a software development or e-commercecompany, etc. Non-limiting examples of the services provided by such aservice provider may include, as non-limiting examples, domain nameregistration and maintenance services, web hosting and maintenanceservices, website development and maintenance services, SSL certificatevalidation, signing and issuance services, installation of SSLcertificates on hosted websites, DNS services (e.g., domain name/URLresolution, and/or hosting a DNS software, database server, relevantzone, or other DNS files and/or a DNS database), email services,calendaring/scheduling services, online storage services, fax services,etc. Any combination of these services may be provided by a singleservice provider.

The user account module(s) 300 may provide access to the serviceprovider's services via the administrative user account. As non-limitingexamples, the user account module(s) 300 may provide access to anadministrative account and/or server-generated control panel interfacefor each of the various services provided through the user account.These one or more control panel interfaces may be accessible via anyclient 220 and may comprise, as non-limiting examples, a web page, aclient side program, an “app,” a server administration interface, etc.In some embodiments, access to the services may be provided via one ormore administration and/or control panel interfaces, possibly generatedby the server(s) 210 and transmitted to clients 220 as webpagesaccessible via the Internet.

To create a user account, the user account module(s) 300 may beconfigured to generate and transmit, for display on the client(s) 220, auser account signup interface, possibly a web page or other client-sideuser interface. The signup interface may be configured to receive, fromthe user, a request to create a user account, including a username andpassword for the user account. The signup interface may be furtherconfigured to receive additional information from and about the user,including contact information such as a phone number, SMS messagingcontact information, email address, etc.

The signup interface may further be configured to transmit the user'sinformation to the server(s) 210. The server(s) 210 may receive thisinformation, and store the information in a database 230 or otherstorage system, as described herein. In some embodiments, such as thatshown in FIG. 3, the information may be stored as a user account datarecord 305 within the database 230, possibly in a user account datatable. Each user account record 305 stored in the database 230 may beassigned a unique user account identification (“user ID,” sometimesreferred to as a customer ID or a shopper ID) 310. In some embodiments,this user ID 310 may be a unique number auto-generated and assigned, bythe database, to the record created for the user account 305 in thedatabase 230, the user ID 310 for each record being auto-incrementedfrom the last. In other embodiments, the user account module(s) 300 mayassign each new user account a unique user ID 310. The user ID 310 maybe included (possibly as a foreign key) within all records stored in thedatabase 230 that are associated with this “master” user account.

The user may create an account according to any means of userinformation collection known in the art. As a non-limiting example, theuser account may be created via a purchase path for one or more productsavailable from the service provider. The user may request, and theserver(s) 210 may receive the request from the client(s) 220, to createthe user account for the user.

During this user account creation process, the user may be prompted tocreate and/or select a username and a password. This username andpassword may be used to authenticate the user when the user accesses theproducts provided by the service provider, including the domain namesoftware module(s) 325 disclosed herein. As a non-limiting example, toaccess the disclosed domain name software module(s) 325, the user may beprompted for the username and password. After a client 230 transmits theusername and password to the server computer, the server(s) 210 maysearch the database 230 to determine if the received username andpassword exist within a user account record 305 stored in the database230. If so, the server(s) 210 may authenticate the user to the domainname software module 325.

The user may also provide additional personal information during theaccount creation process. As a non-limiting example, and for purposes ofthe disclosed invention, the user may provide a location 315 of the userand/or the client(s) 220 being operated by the user and/or a preferredlanguage 320 for the user. The server(s) 210 may therefore be configuredto request, receive and/or store in the database 230, a user accountrecord 305 comprising a username for the user, a password for the user,the location 315 of the user/client and/or the preferred language 320 ofthe user.

The location 315 information may comprise any location 315 provided bythe user or detectible by techniques described herein or known in theart. Non-limiting examples of such a location 315 may include the user'scontinent, country, region, state, province, county, city, neighborhood,street address, zip or postal code, etc. or any combination thereof.

As a non-limiting example: Joe, an owner of a pizza restaurant and auser of the disclosed system, may operate his business from LittleItaly, New York City, New York, USA. As he sets up his user account, hemay provide a username “joespizza” and password “pepperoni.” Asprompted, he may include his preferred languages 320 as English andItalian and may include his location 315 as 123 Restaurant Road, LittleItaly, New York City, N.Y., USA. Joe may also provide additional detailsabout his address, phone number or any other contact or personalinformation to be included in the user account data record 305.

The user can also provide additional information describing a businessor other entity associated with the user and for which the user mayultimately search for a domain name. For example, the user may providethe name of the user's business or a business employing the user. Theuser can then provide additional information describing the businesssuch as its size, location (e.g., mailing address of the business'headquarters, GPS coordinates, city, or any other location information),and any other information relevant to the business. In some embodiments,a type or category of the user's business may also be stored in theuser's account information. The user may explicitly select and identifythe category of the user's business, such as via a selection menuprovided during an account creation process.

The category of the user's business may specify the type of organization(e.g., non-profit, for-profit, governmental) as well as a description ofthe specific market or vertical in which the business operates (e.g.,law-firm, bike shop, catering company). In various embodiments of thepresent system, the business categorization can be as broad or narrow asdesired and may, in some cases, include multiple categorizations ofdifferent breadth and/or type for a single business or other entity. Incircumstances where the user does not have or is not affiliated with abusiness, the user's account may be otherwise categorized. For example,the user may wish to register a domain name for a personal or familyphotograph blog. In that case, the category information provided by theuser may be one of “personal”, or “photo-blog.” Accordingly, not onlymay a category be specified based upon a business that is to beaffiliated with a domain name, but, if no such business exists, acategory may be selected based upon the genre of website that is to behosted at the domain name.

As mentioned above, the category of the user's business may be specifiedexplicitly by the user. In other embodiments, however, the category maybe inferred or otherwise determined by the service provider based uponavailable information. For example, if the category is not explicitlyspecified, the service provider may utilize servers 210 to performkeyword analysis of a website associated with the user's account toidentify keywords stored therein that may indicate that the user isaffiliated with a business or other entity belonging to a particularcategory. For example, if the website includes a number of keywords thatare commonly found on the web pages of online bike shops, the presenceof those keywords on the user's website may allow the service providerto infer that the user's business is a bike shop. Then, having made sucha determination, the service provider may determine that the user isshopping for an additional domain name for the bike shop.

Similarly, if, during the construction of the user's website, the userselected particular website templates that are associated withparticular types of businesses, the selection of those templates may beused to infer that the user's business belongs in a particular category.For example, if the user selected a “small law firm” template whenconstructing the website, the service provider can use that informationto infer that the user is affiliated with a small law firm.

One non-limiting example of the products/services offered by the serviceprovider may include registering domain names for users/customers. Insome embodiments, this service may be provided by a registrar capable ofregistering domain names. As non-limiting examples, the service providermay be a registrar for generic TLDs (gTLD) such as .com, .net, .edu,.org, etc. In the context of the current invention, the registrar mayalso be a registrar of customized gTLDs such as .domainnames, .godaddy,.nyc, .newyork, .littleitaly etc. or country-code TLDs (ccTLD) and/orccTLDs that have an affinity for a specific language or set of languagesand or locale. Non limiting examples may include .us, .it, etc.Registrars may need to take the steps necessary to qualify as registrarsfor these customized TLDs and/or ccTLDs according to qualifying stepsknown in the art.

The registrar may store, in the database 230, information about domainnames registered with the registrar and the TLDs associated with thedomain names (and for which the registrar is authorized to register)330. As non-limiting examples, the registrar may store one or more TLDrecords 335 in the database 230 for each of the TLDs for which that theregistrar is qualified and authorized to register. Within these one ormore TLD records 335, the registrar may associate the TLD that is thesubject of the record(s) 335 with one or more locations 315 and/or oneor more languages 320. In some embodiments, the location(s) 315 and/orlanguages 320 associated with the TLD in the database may be stored inone or more records (not shown) corresponding to the one or more TLDrecords 335. In addition to registering domain names and storinginformation about the domain name registrations, the registrar may alsostore data and/or have access to data about all names in the root.

The registrar may store one or more records of registered domain names330. As non-limiting examples, the records of registered domain names330 may comprise zone files downloaded from a domain name registry.Likewise, records of registered domain names 330 may comprise recordswithin a registrar database 330 created and/or updated each time a newdomain name is registered (or transferred, perhaps via domain nameaftermarket) with the registrar. No limitations should be placed on themanner in which the domain name module 325 determines the availabilityof domain names. As non-limiting examples, the domain name module(s) 325may determine available domain names to be those domain names not listedin the zone files and/or found in the database 230 for a particular textstring combined with a TLD.

The user may access, possibly after authenticating to their useraccount, one or more domain name software modules 325 running on theserver(s) 210. The domain name module(s) 325 may comprise a componentfor recommending, registering and/or administrating domain names. Thiscomponent may further comprise a module for recommending a domain nameand/or TLD if a domain name requested by a user is determined to beunavailable. Recommendations for domain names may include domain namesthat have not yet been registered, domain names available in a domainname aftermarket and/or services for contacting current domain owners todetermine if the current registrant is willing to sell their domainname(s).

As seen in the non-limiting examples in FIGS. 5, 7, 9, 11, 13, 14, 16,and 21 a user interface/control panel for the domain name softwaremodule(s) 325 may be displayed on the client(s) 220. The userinterface/control panel for the domain name module(s) 325 may beconfigured to receive one or more requested domain names from a user. Asseen in FIGS. 5, 7, 9, 11, 13, 14, 16, and 21, the requested domain namemay comprise a text string and/or a selected TLD received from the userand transmitted to the domain name module(s) 325. This text string maycomprise a specific domain or a plurality of random terms and may beused to identify one or more related domain names that are available orsoon will be available for registration.

In some embodiments, the requested domain name and/or keywords may bereceived by alternative user interfaces and transmitted to the domainmodule(s) 325 for candidate domain name generation. For example,keywords may be entered by the user into the search text entry box of anInternet search engine (e.g., GOOGLE, BING). After the keywords havebeen submitted to the domain module(s) 325, the candidate domain namesgenerated by the domain module(s) 325 may then be displayed along withthe results of the Internet search. As such, once a search is performed,the user may be provided with a listing of relevant web pages to thesearch (i.e., a conventional set of Internet search results), as well asa listing of candidate domain names that are relevant to the searchkeywords. The user could then elect to select one or more of thecandidate domain names displayed along with the search results forregistration. In this case, if the a user were to perform an Internetsearch for “how to open a pizza restaurant in Phoenix Ariz.”, inaddition to the standard search results, the user may be presented withthe option to register domain names such as “phoenix-pizza.com”,“pizza,arizona”, “azpizza.net”, and the like.

In some other cases, the requested domain name and/or keywords may beidentified without the user explicitly supplying them via a search forcandidate domain names. For example, when the user attempts to visit aweb page that does not exist, resulting in a 404 error page beingdisplayed, the URL that the user attempted to visit could be parsed intoa number of keywords that may be utilized to execute a candidate domainname search (e.g., performed by domain module(s) 325). The results ofthat search (i.e., a listing of candidate domain names) could then bedisplayed on the 404 error page along with the error message. Thecandidate domain names displayed on the 404 error page could then beselected by the user for registration.

The domain name module(s) 325 may be configured to receive the requesteddomain name or keywords from the user interface on the client(s) 220 (orother source of the domain name or keywords) and search the records ofregistered domain names 330 to determine if the requested domain name ordomain names relevant to the keywords are available. If any such domainnames are available, the domain name module(s) 325 may be configured toreceive a request/selection by the user to register one of the domainnames and may be further configured to register the domain name and/oradministrate the domain name according to any technique for domain nameregistration and/or administration known in the art.

Continuing the non-limiting example above, and as seen in FIGS. 5, 7, 9,11 and 13, a user may type the string “Joe's Pizza” (or alternatively“joespizza”) into a user interface element (possibly a text box) on theuser interface. In the illustrated non-limiting embodiments, the usermay also select a TLD associated with the entered text string as part ofthe domain name search (e.g., “.com” is selected from a drop down inthese non-limiting examples). The displayed control panel may then beconfigured to transmit the entered form data to the domain name module325 running on the server(s) 210. If joespizza.com is available forregistration, the domain name module(s) 325 may be configured totransmit, for display on the client(s) 220, a notification that thedomain name is available, and guide the user through the process ofregistering joespizza.com.

However, if the requested domain name is not available for registration,the domain name module(s) 325 may be configured to calculate, identifyand generate alternative domain names to be suggested to the user. Thealternative and/or additional “spun” domain name may comprise either oneor more similar domain names with the same TLD and/or one or moreavailable domain names with a different TLD. If the “spun” domainname(s) are selected by the user, the domain name module(s) 325 may beconfigured to register the domain name(s) selected by the user, andadministrate the registered domain names accordingly.

Continuing the non-limiting example above, the domain name module(s) 325may be configured to determine that, if joespizza.com is not available,joespizza.net or joespizza.us are available, and may transmit thesesuggested domain names to the client(s) 220 for display. The domain namemodule(s) 325 may be configured to receive a selection of an availabledomain name and guide the user through the process of registering andadministrating joespizza.com.

In embodiments recommending one or more domains with the same (or adifferent) string and a different TLD, the domain name module(s) 325and/or the server(s) 210 may be configured to recommend the TLD, SLD,nth level domain and/or sub domain according to the location 315 of theclient(s) 220 and/or the preferred language 320 of the user of theclient(s) 220. The location 315 of the client(s) 220 should not belimited. As non-limiting examples, any location from an individualresidence to a continent may be included in the definition of a clientlocation, including, but not limited to a housing development,neighborhood, borough, city, county, zip code, state, country, etc.

Thus, the disclosed inventions may recommend location and/or languagespecific SLDs, nth level domains and/or subdomains according to a more“granular” approach to recommending available (or soon to be available)domain names, including specific ccTLDs or gTLDs. Continuing the exampleabove, if Joe has a restaurant in Little Italy in New York City, andjoespizza.com is not available for registration, the domain namemodule(s) 325 may be configured to determine Joe's location 315 and/orpreferred language 320 and recommend alternative domain names usinglocation and/or language specific TLDs, SLDs, nth level domains and orsub domains, such as joespizzalittleitaly.nyc, nycjoespizza.littleitaly,joespizza.nyc, joespizza.newyork, joespizza.littleitaly, joespizza.us,joespizza.it, etc., as non-limiting examples.

To recommend the TLD according to the location 315 and/or the preferredlanguage 320, the domain name module(s) 325 may be configured todetermine the location 315 of the client(s) 220 and/or a preferredlanguage 320 for the user of the client(s) 220 and generate domain namerecommendations based on the TLDs 335 associated in the database 230with the location 315 and/or preferred language 320. To accomplish this,the domain name module(s) 325 may be configured to determine thelocation 315 or preferred language 320 based upon: i) a user account forthe user; ii) a browser cookie 335 stored on the client computer 220;iii) at least one browser setting 340 for a browser 345 running on theclient computer 220; iv) a URL entered into the browser 350; and/or v)an internet protocol address of the client computer 220 on a network200.

The domain name module(s) 325 may be configured to recommend the SLD,nth level domain and/or sub domain within the domain name according toany domain name suggestion techniques known in the art. As anon-limiting example, to recommend an SLD, nth level domain and/or subdomain according to the location 315 and/or the preferred language 320,the domain name module(s) 325 may be configured to identify, within thetext string from the request to determine the availability of the domainname, one or more keywords. The domain name module(s) 325 may be furtherconfigured to generate the SLD, nth level domain and/or sub domain fromthe identified keyword(s), so that the SLD, nth level domain and/or subdomain within the recommended domain name comprises the identifiedkeyword(s).

The domain name module(s) 325 may then be configured to identify thelocation 315 and/or preferred language 320 according to steps disclosedherein, and may include the location 315 and/or preferred language 320as a text string within the generated SLD, nth level domain and/or subdomain. In some embodiments, the location 315 and/or preferred language320 may be appended as a prefix or a suffix to the keyword(s) within thegenerated SLD. The SLD, nth level domain and/or sub domain may then beconcatenated to any gTLD, ccTLD or other TLD to complete the full domainname. In some embodiments, the SLD, nth level domain and/or sub domainmay be concatenated to a TLD generated based on the location 315 and/orpreferred language 320 as disclosed herein.

From the non-limiting example disclosed herein, the domain namemodule(s) 325 may be configured to receive the example text string“Joe's Pizza” or “joespizza” from the domain name module(s) 325 userinterface. The domain name module(s) 325 may be configured to identify,within the text string, the keywords “joes” and “pizza,” and maygenerate the SLD “joespizza” from these keywords. The SLD “joespizza”may then be combined with a text string representing the location 315and/or preferred language 320, which may be appended as a prefix orsuffix to the keywords, resulting in “joespizzalittleitaly” or“nycjoespizza,” as non-limiting examples. The SLD may then beconcatenated to a TLD, possibly based on the location 315 and/orpreferred language 320, thereby generating the domain namesjoespizzalittleitaly.nyc or nycjoespizza.littleitaly, as non-limitingexamples.

In some embodiments, the domain name module(s) 325 are configured tofurther utilize the preferred language 320 in spinning or generatingcandidate domain names. This may involve analyzing the text string toidentify keywords. Then, once the keywords have been identified domainnames can be spun by identifying words that are relevant to the keywordsin the preferred language 320. In the present examples, the text stringincludes the keywords joes and pizza. As such, the spinning process mayinvolve identifying words that are relevant to the word pizza. In thisexample, where the preferred languages can include English and Italian,relevant words may include “restaurant” as well as “ristorante”. Assuch, candidate SLDs may include the English “joespizzarestaurant” andthe Italian, “joespizzaristorante.” When spinning domains, English SLDsmay be associated with an English or predominantly English TLD (e.g.,.com, or .us) and Italian SLDs be associated with an Italian TLD (e.g.,.it).

Not only can the preferred language 320 be utilized to generate bothSLDs and TLDs, but the preferred language 320 may also be used to spindomain names that use characters specific for the preferred language320. For example, if the preferred language 320 uses a Cyrillicalphabet, then the domain names module(s) 325 can be configured togenerate TLD, SLD, nth level domain and/or sub domain combinations thatincludes words, phrases, or acronyms that employ Cyrillic characters.Similarly, domain names that include other accented characters (such asin latin scrip—e.g., é for café) may be generated.

The domain name module(s) 325 may then be configured to compare thegenerated SLD/TLD combination to the registered domain name data in thedatabase 230 to determine if the generated suggested domain names havealready been registered. If not, the SLD/TLD combination may betransmitted to the client(s) 220 for display as a suggested domain name.

In some embodiments, the sources used to determine the location 315 ofthe client(s) 220 and/or the preferred language 320 for the user of theclient(s) 220 (i.e. user record 305, cookie(s) 335, browser setting(s)340, URL 350, IP address, etc.) may be utilized in a “cascading” order.As a non-limiting example, the domain name module(s) 325 and/or theserver(s) 210 may first determine whether a user account data record 305exists for the user, and identify the location 315 and/or the preferredlanguage 320 from the user account data record 305. If no user accountdata record 305 exists for the user, the domain name module(s) 325and/or the server(s) 210 may determine whether one or more cookies 335have been stored on the client(s) 220 and determine the location 315and/or preferred language 320 from the cookie(s) 335. If no cookie 335exists on the server, the domain name module(s) 325 and/or the server(s)210 may determine the location 315 and/or preferred language 320 fromone or more browser settings 340 and so forth.

In embodiments that determine the location 315 and/or preferred language320 based upon a user account for the user, the domain name module(s)325 may be configured to determine whether the database 230 comprisesone or more user account data record(s) 305 for the user. If so, thedomain name module(s) 325 and/or server(s) 210 may be configured toidentify, within the user account data record(s) 305, the location 315and/or the preferred language(s) 320.

One non-limiting example of determining whether the database 230comprises a user account data record 305 for the user may include theuser account module(s) 325 and/or domain name module(s) 325 determiningwhether the user has been authenticated to a user account. In someembodiments, this authentication may be determined according to whethera session variable is included within a current session for the user.The user ID 310 session variable may indicate to the module(s) 300, 325that the user has previously been authenticated by identifying the userID 310 within a user account record 305 in the database 230.

In some embodiments, the user account record 305 comprising the user ID310 may be identified according to a username/password combinationsubmitted to the server 210. The server may then be configured todetermine whether a user account data record 305 is found in thedatabase comprising the username/password combination and/or the user ID310 for the session.

In some embodiments, if no user ID 310 and/or username/passwordcombination has been identified, the server(s) 210 may be configured torequest and receive a username and/or password from the user, anddetermine whether a user account data record 305, comprising theusername and/or password, exists within the database 230. If so, theuser may be authenticated, and the data from the user account datarecord 305 may be made available to the user account module(s) 300and/or the domain name module(s) 325.

Regardless of the method used, once the user account data record 305 isidentified, a location 315 and/or preferred language 320 may beidentified within the user account data record 305 if the user haspreviously provided such information. If the location 315 and/orpreferred language 320 is found within the user account data record 305,the domain name module(s) 325 may be configured to identify one or moreTLD's associated, within TLD data records 335 as described herein, withthe location 315 and/or preferred language 320 in the user account datarecord 305. As seen in the non-limiting example embodiment shown in FIG.5, the domain name module(s) 325 may be configured to generate one ormore recommended domain names including the one or more TLDs 335, SLDs,nth level domains and/or sub domains associated with the location 315and/or preferred language 320. These generated domain names may then betransmitted to the client(s) 220 for display on a user interface and/orcontrol panel.

In embodiments that determine the location 315 or preferred language 320based upon one or more cookies 335 stored on the client(s) 220, thedomain name module(s) 325 may be configured to determine whether thecookie(s) 335 from a previous session are stored on the client(s) 220.If so, the domain name module(s) 225 and/or server(s) 210 may beconfigured to receive the cookie(s) 335 from the client 220 as thecookies are automatically sent by a browser. The domain name module(s)325 may further be configured to identify, within the cookie(s) 335, thelocation 315 and/or the preferred language(s) 320.

In these embodiments, the server(s) 210 may generate and write one ormore browser or other “cookies” 335 to the client(s) 220. The cookie(s)335 may comprise data about a user's Internet session. The data aboutthe user's session may comprise various information about the user,website, and or interactions between the user and various websites.During these interactions, the websites and/or server(s) 210 may writethe cookie(s) 335 to the client(s) 220. The data within the cookie(s)335 may comprise, as non-limiting examples, the location of the clientcomputer 315 and/or a preferred language for a user of the clientcomputer 320. As non-limiting examples, in some embodiments, the usermay provide the location 315 and/or preferred language 320 writtenwithin the cookie(s) 335. In other embodiments, the cookie(s) 335 may bewritten by the server(s) 210 based upon a location 315 and/or orpreferred language 320 as determined by particular visited websitesand/or web pages. As non-limiting examples, the information from thewebsites may be determined via URL or browser settings as describedbelow.

If the domain name module(s) 325 and/or server(s) 210 determine that thecookie(s) 335 have been stored on the client(s) 220 and comprise thelocation 315 and/or preferred language 320, the server(s) 210 may beconfigured to identify data within the cookie(s) 335 comprising thelocation 315 and/or preferred language 320. If the location 315 and/orpreferred language 320 is found within the cookie(s) 335, the domainname module(s) 325 may be configured to identify one or more TLD'sassociated, within TLD data records 335 as described herein, with thelocation 315 and/or preferred language(s) 320. As seen in thenon-limiting example embodiment shown in FIG. 7, the domain namemodule(s) 325 may be configured to generate one or more recommendeddomain names including the one or more TLDs, SLDs, nth level domainsand/or sub domains associated with the location 315 and/or preferredlanguage(s) 320. These generated domain names may then be transmitted tothe client(s) 220 for display on a user interface and/or control panel.

In embodiments that determine the location 315 or preferred language 320based upon one or more browser settings 340 stored within an Internet orother browser 345 running on the client(s) 220, the domain namemodule(s) 325 may be configured to request and/or receive, from theclient(s) 220, the one or more browser settings 340. The browser 345running on the client(s) 220 may include various settings andconfiguration information, which may include, as non-limiting examples,a geo location 315 of the client(s) 220 and/or a language preference 320setting for the operator of the browser 345.

As a non-limiting example, the browser 345 may be “geo enabled,”allowing the browser 345 to determine and store the physical location315 of the client(s) 220. The location of the browser 345 may bedetermined using “geo location providers,” which may provide requestedgeo location 315 information from a source provider (e.g., Google wouldbe a source provider for users determining their geo location fromGoogle's Chrome browser). The source provider may then provide therequested geo location 315 information. In other embodiments, thebrowser 345 may send local network 200 information to the sourceprovider (e.g., Google Location Services) to get geo location 315information. In other embodiments, the location can be inferred usingother data. For example, if the user is using a mobile device to accessthe service provider, the service provider may be configured todetermine a cellular network (e.g., phone or telecommunications network)being used by the user. The location of the user may then be determinedto be within a region in which the cellular network operates.Alternatively, the service provider may analyze an Internet subnet fromthe user's request originated. The service provider can then translatethat subnet to define a geographical region in which the user may belocated.

The browser 345 may then store the geo location 315 information and/orshare the client's 220 geo location 315 with the requesting server(s)210. Using the browser's 345 geo location 315 settings, the browser mayallow all sites to track the client's 220 physical location 315. Othernon-limiting examples of location-based browser settings 340 may includeFirefox: (e.g., {“location”: {“latitude”: 48.861426,2.338929,“longitude”: 2.338929, “accuracy”:20.0} }), or, if the browser 345 has ageo.enabled setting set to true, the physical location 315 informationmay be transmitted and/or pulled from the browser's 345 about:configinformation.

The browser settings 340 received by the server(s) 210 may also includea preferred language 320 for which website content displayed on thebrowser 345 is to be generated and displayed. As non-limiting examples,for Internet Explorer, the server(s) 210 may receive the values and/orsettings from the browser's 345 Tools>Internet Options>General>Languagesparameters. Likewise, for Firefox, the server(s) 210 may receive thevalues and/or settings from tools>options>content>languages and/or awindow.navigator.language function to transmit a string representing thelanguage version of the browser 345.

Regardless of the method used, once the browser settings for location315 and/or preferred language 320 are be identified within the browsersettings 340, the location 315 and/or preferred language 320 identifiedwithin the browser settings 340 may then be used to identify, within thedatabase 230, one or more TLD's records 335 previously associated,within the database 230, with the location 315 or preferred language 320as described herein.

If the server(s) 210 determine that the browser settings 340 have beenstored on the client(s) 220 and comprise the location 315 and/orpreferred language 320, the server(s) 210 may be configured to identifydata within the browser setting(s) 340 comprising the location 315and/or preferred language 320. If the location 315 and/or preferredlanguage 320 is found within the browser settings 340, the domain namemodule(s) 325 may be configured to identify one or more TLD'sassociated, within TLD data records 335, with the location 315 and/orpreferred language 320. As seen in the non-limiting example embodimentshown in FIG. 9, the domain name module(s) 3 may be configured togenerate one or more recommended domain names including the one or moreTLDs, SLDs, nth level domains and/or sub domains associated with thelocation 315 and/or preferred language 320. These generated domain namesmay then be transmitted to the client(s) 220 for display on a userinterface and/or control panel.

In embodiments that determine the location 315 and/or preferred language320 based upon a URL 350 used to send a request to the server(s) 210from a browser 345 running on the client(s) 220, the domain namemodule(s) 325 may be configured to identify a substring within the URLrepresenting, as non-limiting examples, a location 315 of the client(s)220 and/or a preferred language 320 for the operator of the browser 345.

As a non-limiting example, the domain name module(s) 325 may beaccessible via a web page on a registrar website. To access the userinterface/control panel for the domain name module(s) 325, a user mayenter the URL http://it.domaincontrolpanel.nyc into the appropriateaddress bar in a web browser 345. For purposes of this non-limitingexample, the sub domain “it” may indicate that the preferred languagefor the user that accessed the website is Italian. The customized TLD“.nyc” may indicate that the location of the user is New York City, N.Y.Such a customized URL may be used, among other things, to customize awebsite content to a specific client location 315 and/or to a primarylanguage 320 of the website/domain name module 325 user.

The domain name module(s) 325 may be configured to receive the requestto resolve the web page, and further analyze the received request URL350 to determine and identify one or more sub strings within the URL 350representing a client location 315 for which a website content should becustomized and/or a primary language 320 for which the website contentshould be customized. As non-limiting examples, the sub string maycomprise a sub domain, TLD and/or a website path representing subfolders within the website (e.g., /it/or/nyc/). In this non-limitingexample, the domain name module(s) 325 may further be extrapolateadditional information from the URL. For example, the domain namemodule(s) 325 may be configured to determine, based on the user'spreferred language 320 being Italian, and the location 315 of theclient(s) 220 being New York City, that the user is accessing the webpage from Little Italy in New York City.

If the server(s) 210 determine that the URL comprises one or moresubstrings representing a client location 315 and/or a primary/preferredlanguage 320 for which the website content should be customized, thedomain name module(s) 325 may be configured to identify one or moreTLD's associated, within TLD data records 335, with the client location315 and/or primary/preferred language 320. As seen in the non-limitingexample embodiment shown in FIG. 11, the domain name module(s) 325 maybe configured to generate one or more recommended domain names includingthe one or more TLDs, SLDs, nth level domains and/or sub domainsassociated with the client location 315 and/or primary/preferredlanguage 320. These generated domain names may then be transmitted tothe client(s) 220 for display on a user interface and/or control panel.

In embodiments that determine the location 315 and/or preferred language320 based upon an IP address of the client computer, the domain namemodule(s) 325 may be configured to identify the IP address of theclient(s) 220 on the network. The domain name module(s) 325 may beconfigured to map the IP address to a real-world geographic location 315by requesting, from a library mapping at least one IP address to atleast one geo location, the location 315 of the client computer 220based upon the IP address.

This may be accomplished using one or more available geo locationdatabases (e.g., Ip2location, MaxMind, Tamo Soft, IPligence). Such geolocation databases may get their contact, IP and/or registrationinformation from WHOIS databases, which may be accurate down to zip codelevel. When an organization requires a block of IP addresses, a requestmay be submitted and allocated IP addresses may be assigned to arequested ISP. The server(s) 210 may then use this information todetermine the location 315 and/or an associated language 320 of the IPaddress (i.e., the preferred language may be extrapolated from thelocation 315 determined by the IP address).

The domain name module(s) 325 may be configured to identify one or moreTLD's associated, within TLD data records 335, with the client location315 and/or preferred language 320. As seen in the non-limiting exampleembodiment shown in FIG. 13, the domain name module(s) 325 may beconfigured to generate one or more recommended domain names includingthe one or more TLDs, SLDs, nth level domains and/or sub domainsassociated with the location 315 and/or preferred language 320. Thesegenerated domain names may then be transmitted to the client(s) 220 fordisplay on a user interface and/or control panel.

In some embodiments of the present system, the user may enter a textstring that is written in a first language, but wish to be presentedwith candidate domain names that are in a second language. For example,a user with a successful business in France may wish to enter theEnglish market. But, because English is a second language, the user maynot be comfortable searching for domain names in English using Englishterminology.

In that case, the domain name module(s) 325 may enable the user to entera domain name search string or query in a first language, but thenselect a different language in which the candidate domain names shouldbe generated and presented. With reference to FIG. 14, therefore, anexample is presented in which the user has entered a first domain namesearch in the French language. The search is for “voiture électrique”,which means “electric car”. The user has then executed the search, butrequested that the candidate domain names be presented in English. Asillustrated, therefore, the listing of candidate domain names based uponthe user's search criteria are all presented in English.

To perform such a search, the domain name module(s) 325 (e.g., executedby server(s) 210) may be configured to first identify the language ofthe text string entered by the user. There are a number of knownlibraries that can be used to identify the language of a particular textstring, such as language detection libraries provided by GOOGLE orMICROSOFT. To use the libraries, a computer program included within thelibrary is executed against the text string. After processing thestring, the library will then return a name of a language. The languageidentified by the library is the language, selected from a number ofcandidates, having the highest probability of being the language inwhich the text string is written. Alternatively, the language of thetext string may be inferred by the preferred language 320 of the user,as described herein. If the user's preferred language 320, for example,is French, the domain name module(s) 325 may determine that the textstring was entered in French.

Having identified the language of the text string, the domain namemodule(s) 325 can then identify keywords in the text string andtranslate those keywords into the selected desired language. Oncetranslated, the domain name spinning process, as described herein, canproceed to generate a number of candidate domain names in the desiredlanguage as specified by the user using the translated keywords.

In addition to translating the keywords in the text string into thedesired language, the domain name module(s) 325 may be furtherconfigured to generate candidate domain names that include TLDsassociated with the desired language. As such, in the example depictedin FIG. 14, because the desired language is English, the candidatedomain names include .us and .uk TLDs. Conversely, if the desiredlanguage included German, TLDs associated with that language (e.g., .de,.at and/or .ch) would be promoted within the listing of candidate domainnames generated by the domain name module(s) 325. To do this, the domainname module(s) 325 may store a database or lookup table that identifies,for a number of possible languages, a listing of associated TLDs. Usingthe lookup table, the domain name module(s) 325 can then generatedcandidate domain names for all TLDs associated with the desiredlanguage.

In some embodiments, the domain name module(s) 325 may be furtherconfigured to generate candidate domain names taking into account thetype or category of the user's business (or other entity), as describedabove. In the case of TLDs, the domain name module(s) 325 may beconfigured to store a table that identifies, for each potential businesscategory, a preference ranking for potential TLDs. The categories may bequite broad, for example, so that TLDs may be ranked in order ofpreference for non-profit organizations, for-profit organizations, andpersonal sites. Alternatively, the categories may be relatively narrow,so that TLDs may be ranked for specific types of businesses such as lawfirms, restaurants, humane societies, and the like. Table 1, shownbelow, shows an example mapping of business type to TLD preferenceranking.

TABLE 1 Business Category 1st TLD 2nd TLD 3rd TLD Profit Company .com.co .company Non-Profit Company .org .net .com Personal .com .co .net

As shown in Table 1, a number of high-level business types are defined.Then, for each business type, three different ranked TLDs are presented.For the given organization type, the ‘1st TLD’ is a more preferred TLDthan the ‘2nd TLD’ and so on. Although only three ranked TLDs are shownin this example, it should be understood that any number of TLDs may beranked for each business type.

Table 2, below, shows an alternative TLD preference ranking in whichTLDs are ranked for more specific business types. In the table, for eachcategory, five different TLDs are ranked in order of preference. Asillustrated, the ranked TLDs may include gTLDs, or any variety of TLDsthat are available for registration. In general, any number of TLDpreference rankings can be generated for each business category.

TABLE 2 Business Category 1st TLD 2nd TLD 3rd TLD 4th TLD 5th TLD LawFirm .com .lawyer .co .law .legal Bike Shop .com .bike .it .fr .ride PetRescue .org .com .rescue .net .co.us

The TLD ranking for each business type may be generated by any suitablemechanism. In some cases, the rankings can be generated for eachbusiness type based upon the knowledge of marketing experts that areable to value TLDs for each business type. In another implementation,the rankings can be generated by the service provider by analyzing thedomain name registration records of its customers. By analyzing thecontents of database 230, for example, and, particularly within userrecord(s) 305 therein, the service provider can identify the domain nameregistrations for a large number of users. To the extent those domainname registrations are associated with a specific business or entity andthe user records(s) 305 identify a business type, the service provider(e.g., utilizing server(s) 210) can analyze the records to identify themost popular TLDs for domain name registrations for each business typeor category. That popularity can then be used to generate a preferencelisting of TLDs for each business type or category. The preferencelistings may include only conventional TLDs, or may also includecombinations of ccTLDs and gTLDs, as necessary.

Once the TLD preference table has been generated, the table can be usedto boost the prominence of particular TLDs during the candidate domainname spinning or generation process. FIG. 15, for example, shows amethod for generating candidate domain names where the candidate domainnames include TLDs ranked according to a preference table.

In step 1502 the account data associated with a user submitting a searchstring is identified. The search string may include a desired domainname or may include a text string containing of a number of separatesearch terms. The user may be identified using any of the mechanismsdescribed herein. The account data may include one or more userrecord(s) 305.

Once identified, the account data is retrieved and, in step 1504, theaccount data is analyzed to identify a business type of a businessassociated with the user. After the business type is identified, in step1506 a ranked listing of candidate TLDs is identified for the businesstype.

After the ranked listing of TLDs is identified, in step 1508, a numberof candidate domain names can be generated based upon both the querysearch string and the ranked order of TLDs for the user's business type.As discussed above, any suitable technique may be used to generate orspin the candidate domain names. These techniques can be similarly usedto incorporate weightings allocated to the TLDs based upon the TLDpreferences that are, in turn, based upon the user's business type. Theweightings for the TLDs in the domain name spinning can be calculatedsuch that the spinning algorithms are biased in favor of TLDs havinghigher preferences, while TLDs having lower preferences are disfavoredby the domain name spinning algorithm.

The use of the TLD preferences in generating candidate domain namesmakes it more likely that the user will be presented with candidatedomain names that include TLDs more relevant to the user's business. Forexample, if the user's business is a non-profit organization, it wouldnot necessarily be helpful to only suggest ‘.com’ domain names to theuser. In some cases, many non-profit organizations do not use a ‘.com’address as their primary domain name. Accordingly, the present methodwould ensure that a user with a non-profit business is presented withcandidate domain names that are weighted to include ‘.org’ domain names,or some other suitable TLD that is more preferred than the .com TLD.

Similarly, when the TLD preferences include preference listings forrelatively precise business types, a user with a business of, forexample, a bike shop, will be presented with listings of candidatedomain names having TLDs that are preferred for that type of business,while another user with a different type of business would be presentedwith candidate domain names well suited to that user's business.

Finally, after the candidate domain names have been generated, thelisting of candidate domain names can be transmitted to the user in step1510. The user can then select one of the candidate domain names forregistration, or could enter a different search string to see adifferent set of results. An example user interface is presented in FIG.16.

As shown in FIG. 16, the user has executed a search for candidate domainnames relevant to the string ‘Dog Rescue’. After the user submitted thesearch, the service provider determined that the user is affiliated witha pet rescue organization (this information could be stored within userrecord(s) 305 of the user, for example). Having identified the type oforganization that is affiliated with the user, the service provider isable to identify the TLDs that are preferred for that type oforganization. A number of suitable candidate domain names can then bespun and offered for registration by the user.

In some cases, because different businesses may have different TLDpreferences in different geographical regions, the TLD preferences canbe further broken down by region. Table 3, below, for example, shows anumber of TLD preferences for different business types, where thepreferences are broken down by geographical region.

TABLE 3 Business Category - Region 1st TLD 2nd TLD 3rd TLD ProfitCompany - .com .co .net USA Profit Company - .com .co.uk .eu UnitedKingdom Profit Company - .fr .com .eu France Non-Profit Company - .org.co .com USA Non-Profit Company - .org.uk .uk .net United KingdomNon-Profit Company - .org .fr .eu France Personal - USA .com .us .netPersonal - United .uk .net .com Kingdom Personal - France .fr .eu .net

The geographic preferences for TLDs can be generated in much the samemanner as the TLD preference data contained within Table 1 and Table 2,above. For example, one or more persons, knowledgeable of the relevanceof different TLDs in different geographical regions may construct thetable by hand. Alternatively, user record(s) 305 for a number ofdifferent domain name registrations could be analyzed to determine howfrequently different TLDs are used in domain name registrations forbusinesses of particular types that are located in particular geographicregions. With that data collected, the table could be generatedautomatically.

Having constructed the table, FIG. 17 is a flowchart illustrating amethod for generating candidate domain names where the candidate domainnames include TLDs ranked according to a preference table that isdelineated based upon business type and location.

In step 1702 the account data associated with a user submitting a searchstring is identified. The search string may include a desired domainname or may include a text string containing of a number of separatesearch terms. The user may be identified using any of the mechanismsdescribed herein. The account data may include one or more userrecord(s) 305.

Once identified, the account data is retrieved and, in step 1704, theaccount data is analyzed to identify a business type of a businessassociated with the user as well as a location of the business. Afterthe business type and location are identified, in step 1706 a rankedlisting of candidate TLDs is identified for the business type and forthe location. If the table containing the listing of ranked TLDs doesnot include a specific entry for a region incorporating the location ofthe user's business, the table may include a default TLD preference thatmay be utilized.

After the ranked listing of TLDs is identified, in step 1708, a numberof candidate domain names can be generated based upon both the requestsearch string and the ranked order of TLDs for the user's business typeand location. As discussed above, any suitable technique may be used togenerate or spin the candidate domain names. These techniques can besimilarly used to incorporate weighting allocated to the TLDs based uponthe TLD preferences based upon the user's business type. The weightingsfor the TLDs in the domain name spinning can be weighted such that thespinning algorithms are biased in favor of TLDs having higherpreferences, while TLDs having lower preferences are disfavored by thedomain name spinning algorithm.

The use of the location or region-based TLD preferences in generatingcandidate domain names makes it more likely that the user will bepresented with candidate domain names that include TLDs more relevant tothe user's business. For example, if the user's business is a non-profitorganization in the United Kingdom, it would not necessarily be helpfulto only suggest ‘.com’ domain names to the user. Most non-profitorganizations do not use a ‘.com’ address as their primary domain name.Accordingly, the present method could ensure that a user with anon-profit business in the United Kingdom is presented with candidatedomain names that are weighted to include ‘.org.uk’ and ‘.uk’ domainnames.

Similarly, when the TLD preferences include TLD preference listings forrelatively precise business types, a user with a business of, forexample, a bike shop located in France, will be presented with listingsof candidate domain names having TLDs that are preferred for that typeof business in that geographic region, while another user with adifferent type of business in another location would be presented withcandidate domain names well suited to that user's business.

Finally, after the candidate domain names have been generated, thelisting of candidate domain names can be transmitted to the user in step1710. The user can then select one of the candidate domain names forregistration, or could enter a different search string to see adifferent set of results.

In a similar manner to the ranking of TLDs based upon a businesscategory and location, so too can keywords or phrases that appear inSLDs, nth level domain and/or sub domains of the candidate domain namesbe ranked.

To rank the keywords in the candidate domain names, the service providermay again analyze the existing domain name registration data stored inuser record(s) 305 of database 230. The existing domain nameregistrations will then be grouped by business category and geographicregions based upon data stored in user record(s) 305. The registereddomain names can then be parsed to identify individual keywords thatappear in SLDs, nth level domains and/or sub domains of the registereddomain names. The keywords can then be counted to establish the mostpopular keywords for different business categories in the differentgeographical regions.

The result of this analysis could be used to identify domain namekeywords that are popular for particular business categories inparticular regions. For example, the data may indicate that for a bikeshop located in the United States, preferred keywords include “bike”“bicycles” and “USA”. Conversely, for a bike shop located in Italy,preferred keywords may include “bici”, “bicicletta”, and “negozio”.Those keywords can then be promoted in the results of any candidatedomain name generation process implemented by, for example, the domainname module(s) 325.

In some embodiments, the domain names suggested to the user may beranked according to the location 315 and/or preferred language 320. Theuser interface may be configured to receive a selection from thedisplayed domain names and transmit the selection of the at least onedomain name for registration, possibly by the domain name module(s) 325.

In some embodiments, the present system may be configured to receive aquery for candidate domain names and then, in response to that query,rather than generate a listing of individual candidate domain names thatcan individually be registered by the user, recommend or displaypackages of domain names to be registered. There are a number of reasonsfor why this can be beneficial. First, in a particular marketplace,consumers may be used to using a variety of different TLDs. In theUnited Kingdom, for example, businesses may be equally likely toregister .com and .uk domain names. If a business were to only registerthe .com domain name, a competing business could (either intentionallyor accidentally) register the same SLD with the .uk TLD. If that were tooccur, consumers in the United Kingdom, being equally comfortable with.com and .uk domain names may be confused as to which domain name to usefor the business. Accordingly, in this example, a business registering adomain name in the United Kingdom may wish to register a package thatincludes the desired domain name with both the .com and .uk TLDs.

In some cases, in addition to recommending a package of domain namesthat is well suited to a particular marketplace, businesses may wish toregister packages of domain names for defensive reasons. For example, ina particular market or geographical region, or for particular types ofbusinesses, some TLDs may be popular amongst individual perpetratingfraud, such as individuals implementing phishing scams. In that case, abusiness may wish to register their SLD with particular TLDs in aneffort to prevent that abuse, even if those domain names would berelatively unlikely to be visited by customers.

FIG. 18 is a flowchart illustrating a method for recommending a packageof domain names for registration based at least in part upon a businesscategory or keyword. The method illustrated in FIG. 18 may be performed,for example, by the service provider of the present disclosure.

In step 1802, a query for a set of candidate domain names is receivedfrom a user. As described above, the query may include a domain nameitself, or a number of keywords that may be used to identify a number ofcandidate domain names related to the keywords. The query may bereceived by one or more server 210 operated by a service provider via anelectronic communications network, such as network 200. The query may beentered by a user into a client 220 computer using any suitableinterface arranged to receive such a query and cause the transmission ofthe query to the service provider.

Having received the query in step 1802, in step 1804 the query isprocessed by the server(s) 210 to identify a business category orkeywords. This may involve, as described above, analyzing one or morerecords in the user's account information to identify a category of abusiness associated with the user. The business may be one owned oroperated by the user, or one by which the user is employed. The categorymay define a general category for the business (e.g., non-profit,profit, governmental, etc.), or be a more specific category for thebusiness (e.g., bike shop, law firm, bakery, and the like). In othercases, the server(s) 210 may analyze the content of one or more otherwebsites associated with the user to identify keywords therein that maybe utilized to identify a particular business category.

This step may involve, in addition to identifying a category for theuser's business, also identifying a location or region associated withthe business. For example, the location may be identified by a mailingaddress of the business' headquarters, GPS coordinates, city, or anyother location information, all of which may be stored in the user'saccount information, as described above.

Alternatively, in step 1804 the service provider may instead identify anumber of keywords that appear in the query. If the query was originallyprovided by the user in the form of keywords (e.g., the query was “pizzarestaurant arizona”), then no processing is required and those keywordsmay be utilized. If, however, the query included a domain name, theservice provider may utilize any suitable method to identify keywordsthat may appear within the domain name. Additionally, once identified,the service provider may rank the keywords so as to identify the mostprominent keywords within the query.

In some embodiments, the identification of keywords in the query onlyoccurs if a suitable category for a business associated with the usercannot be identified. In other embodiments, though, the service providermay be configured to always identify the keywords in the user's queryand to not identify a business category.

After identifying either the business category or keywords in step 1804,a domain name registration map is determined for either the businesscategory or the keywords in step 1806, and, optionally a location.

In the present disclosure a domain name registration map is arepresentation, for a particular business category or set of keywords,of the number of existing domain name registrations broken down by TLD.The domain name registration map can be generated using any suitableanalysis approach for existing domain name registrations. In oneembodiment, data stored within public databases such as the DNS and/orthe SRS can be analyzed to generate the domain name registration map.Alternatively, one or more user records maintained by the serviceprovider could be used to generate the domain name registration map.

The domain name registration maps utilized in the present system mayrepresent data accumulated world-wide or may be restricted to aparticular geographical region. For example, a domain name map could becreated to show the popularity of different TLDs in the domain names ofrestaurants across the world. Or, conversely, a domain name map could becreated to show the popularity of different TLDs in the domain names ofrestaurants located within a particular geographical region, such as theUnited States or Italy.

FIG. 19A, for example, illustrates a domain name registration map for aparticular business category and a particular region. In this example,the business category is for restaurants and the region is Russia. Onthe horizontal axis, the domain name registration map lists a number ofdifferent TLDs. The vertical axis of the domain name registration maprepresents the relative popularity of each TLD. The vertical axis may bein the units of the total number of registrations or a percentage of thetotal number of registrations.

The domain name registration map of FIG. 19A may be generated using anysuitable method. In one embodiment, a large number of websites availablevia the Internet may be categorized based upon keywords that appear intheir content. This may be performed, for example, by spidering theInternet to collect content from a large number of websites. Thatcontent can then be analyzed to determine whether particular keywordsappear in the content enabling the websites to be associated with aparticular business category and to identify a location for the website(this may be determined, for example, by identifying a mailing addressor office address that appears on the website or analyzing the IPaddress of the server hosting the website). Once the websites have beencategorized and associated with a particular location, DNS entries forthe websites that have been placed into the category of interest andthat fall within the desired geographical region can be analyzed toidentify all the domain name registrations that point to those websites.The domain name registrations can then be summed up to identify thenumber of registrations in each TLD enabling the domain name map to becreated.

In some embodiments, the domain name map may be generated using userrecord data accessible to the service provider. This may be moreefficient than relying on public data sources because the serviceprovider's user records may already store a business category for eachwebsite as well as a location.

In creating the domain name registration map, it is not necessary thatevery website that is available via the Internet and that meets thecategory and location criteria be analyzed. Instead, it may only benecessary that the domain name registration information for arepresentative sample set of websites meeting the category and locationcriteria be analyzed.

FIG. 19B illustrates a second domain name registration map for aparticular set of keywords and a particular region. In this case, thekeywords are the Italian words for bike and shop: “bicicletta” and“negozio” and the region is Italy. On the horizontal axis, the domainname registration map lists a number of different TLDs. The verticalaxis of the domain name registration map represents the relativelypopularity of each TLD. The vertical axis may be in the units of thetotal number of registrations or a percentage of the total number ofregistrations.

The domain name registration map of FIG. 19B may be generated using anysuitable method. In one embodiment, a large number of website may beanalyzed in order to determine a location for the websites. This may beperformed, for example, by spidering the Internet to collect contentfrom a large number of websites. That content can then be analyzed toassociate each website with a particular location. Once locations havebeen established for the websites, DNS entries for the websites thatfall within the desired geographical region can be analyzed to identifyall the domain name registrations that point to those websites. Thedomain name registrations can then be summed up to identify the numberof registrations in each TLD enabling the domain name map to be created.

In some embodiments, the domain name map may be generated using userrecord data accessible to the service provider. This may be moreefficient than relying on public data sources as the service provider'suser records may already store a location data for each user record.

In creating the domain name registration map, it is not necessary thatevery website that is available via the Internet and that meets thecategory and location criteria be analyzed. Instead, it may only benecessary that the domain name registration information for arepresentative sample set of websites meeting the category and locationcriteria be analyzed.

Returning to FIG. 18, once the domain name registration map has beendetermined for either the business category or key words (and,optionally, location), in step 1808 a TLD package is created using thedomain name registration map. The TLD package includes a listing of TLDsfrom the domain name registration map that are most frequentlyregistered for a given business category or domain name keywords (and,optionally, for a particular geographical region). The TLD package canbe generated, for example, by selecting the N most popular TLDs for thedomain name registration map, where N is an integer. The value of N canbe selected in any suitable manner. In some embodiments, N is fixed to avalue (e.g., ‘5’) so that the TLD package will always include the 5 mostpopular TLDs. In some cases, the value of N depends on one or morevariables. For example, N may have different values for differentbusiness categories, keywords, or locations. For example, when thelocation is in Europe where many businesses have customers in arelatively large number of countries, the value of N may be higher thanin North America, where a business' customers tend to be in a muchsmaller number of countries. In other embodiments, the TLDs listed inthe TLD package may be those in the domain name registration map thatexceed a particular percentage of the total number of registrations.Referring again to FIG. 19A, an example TLD package based on the domainname registration map may include the TLDs .com, .co.ru, .bike., and.pϕ.

In some embodiments, the TLD package may be expanded to include TLDsthat may be a potential source of phishing or scam communications. Byincluding such TLDs in the TLD package, the user may be given anopportunity to preemptively register domain names that may otherwise beused to target the user's customers. For example, certain TLDs may beidentified as popular sources of scam communications, such as phishingattempts. In that case, those TLDs may be added to the TLD package toprovide the user any opportunity to defensively register domains thatmay otherwise be registered by fraudsters.

Referring to FIG. 18, once the TLD package is determined, a number ofcandidate domain name packages are generated in step 1810. Eachcandidate domain name package includes a collection of domain names thatare 1) available for registration, and 2) includes domain names witheach TLD in the TLD package. Any suitable method may be used to generatethe candidate domain name packages.

For example, FIG. 20 is a flowchart depicting a method for generating acandidate domain name package. In step 2002, a candidate domain name isgenerated for a primary TLD in the TLD package. The primary TLD may bethe most popular TLD in the TLD package (the popularity may bedetermined based upon the relevant domain name map). Once the primaryTLD package is generated, a candidate domain name can be generated forthe primary TLD using the user's original query (see, for example, thequery received in step 1802 of FIG. 18). Any suitable domain namespinning technique may be utilized to generate the candidate domain namefor the primary TLD using the query data and, optionally, any otherinformation available to the service provider.

Once the first candidate domain name has been generated for the primaryTLD, in step 2004 it is determined whether the SLD of the firstcandidate domain name is available for registration for all the otherTLDs in the TLD package. If so, a candidate domain name package isgenerated including the first candidate domain name (in the primary TLD)as well as the candidate domain names made up of the SLD of the primarydomain name and the other TLDs in the TLD package in step 2006. Forexample, if a user performed a query for candidate domain names usingthe query “pizza restaurant phoenix” and with a TLD package thatincludes the TLDs .com, .us. and .az, where .com is the most popularTLD, the system may identify a first candidate domain name for the .comTLD. For example, the first candidate domain name may be‘phoenix-pizza.com’. The system would then check to see whether the SLD‘phoenix-pizza’ is available with .us and .az TLDs. If so, then thesystem may generate a candidate domain name package that includes‘phoenix-pizza.com’, ‘ phoenix-pizza.us’, and ‘phoenix-pizza.az’.

Once the candidate domain name package has been created, the package canbe offered to the user for registration of all domain names in thecandidate domain name package.

If, however, in step 2004 it is determined that the SLD of the firstcandidate domain name is not available for registration for all theother TLDs in the TLD package, the method returns to step 2002 and a newcandidate domain name is generated for the primary TLD. Once the newcandidate domain name is generated the method moves to step 2004 and theSLD of the new candidate domain name is check for availability in theother TLDs of the TLD package.

As described above, step 2004 involves checking the SLD of the candidatedomain name with the primary TLD for availability in the remaining TLDsof the TLD package. In various embodiments, the SLD may be translatedbefore being checked for availability in the various TLDs. Where aparticular TLD is associated with a specific language, for example, theSLD may be translated into that language before being checked foravailability in that TLD. For example, if a user performed a query forcandidate domain names using the query “bike shop phoenix” and with aTLD package that includes the TLDs .com, .us. and .it, where .com is themost popular TLD, the system may identify a first candidate domain namefor the .com TLD. For example, the first candidate domain name may be‘phoenix-bike.com’. The system would then check to see whether the SLD‘phoenix-bike’ is available with the .us TLD. When checking the .it TLD,however, the SLD may be translated so that the system checks whether theSLD ‘phoenix-bicicletta’ is available with the .it TLD. If so, then thesystem may generate a candidate domain name package that includes‘phoenix-bike.com’, ‘ phoenix-bike.us’, and ‘phoenix-bicicletta.it’.

In another embodiment, the two approaches described above may becombined so that a candidate domain name package would include a firstset of candidate domain names for each TLD in the TLD package with thesame SLD and then additional candidate domain names for TLDs that areassociated with different languages.

In another implementation, a candidate domain name package may begenerated by identifying a suitable candidate domain name for each TLDin the TLD package without requiring that the SLDs of each candidatedomain name be the same or translations of one another.

Once the candidate domain name package has been generated, one or morepackages can be offered to the user for registration via a suitable userinterface. For example, FIG. 21 depicts an example user interfaceenabling a user to register a candidate domain name package afterexecuting a search. In the example depicted in FIG. 21, the user isaffiliated with a pet rescue organization located in Arizona. The userhas performed a domain name search using the search string “dog rescue.”The user's business is an organization that falls into the category of‘pet rescue’ and is located in Arizona. After determining the candidatedomain name map for organizations that fall into that category and arelocated in the United States (i.e., the region encompassing Arizona),the system has identified a TLD package of .com, .org, and .rescue, with.com being the primary TLD. Using the methods described above, twodifferent candidate domain name packages have been created.

The first package 2102 includes a package of domain names where the SLDsare identical for each TLD in the TLD package. The second package 2104includes candidate domain names where the best candidate domain name wasgenerated for each TLD independently.

In various embodiments, when a set of candidate domain names have beengenerated (whether in the form of individual candidate domain names orpackages of candidate domain names), the candidate domain names can befiltered before being displayed for registration by a user. Thefiltering could involve removing potentially offensive or dangerousdomain names from the listing of candidate domain names. In some cases,filtering may involve not removing any of the candidate domain names andinstead making the user aware of the risk of registering a potentiallyoffensive or dangerous domain name.

FIG. 22 is a flowchart illustrating an example method for filtering anumber of candidate domain names. The method may be performed by theservice provider of the present disclosure (e.g., utilizing theserver(s) 210), for example, as part of a process of generating alisting of candidate domain names for a user. In step 2202 a number ofcandidate domain names are received. The candidate domain names may begenerated, for example, in response to a query received from a user. Thequery may include a number of keywords and the candidate domain namesmay be relevant to those keywords.

After the candidate domain names are received, the candidate domainnames may be filtered to remove or identify candidate domain names thatinclude taboo words (step 2204). The taboo words may be international sothat any candidate domain name that contains a taboo word will befiltered. In some embodiments, however, the taboo words may beregionalized because words that are taboo in one region may not beconsidered taboo in other geographical regions. Accordingly, a first setof taboo words may be defined for a first geographical region and asecond set of taboo words may be defined for a second geographicalregion. The location of the user will determine which set of taboo wordsare used to filter the candidate domain names. If the location of theuser falls within a region having the first set of taboo words,candidate domain names that contain any of those taboo words may befiltered. Conversely, if the location of the user falls within a regionhaving the second set of taboo words, candidate domain names thatcontain any of those taboo words may be filtered.

The candidate domain names may also be filtered for geographicalrestrictions in step 2206. For example, some of the candidate domainnames may include gTLDs that are affiliated with a particular place orregion (e.g., .nyc or .arizona). Sometimes those gTLDs are onlyauthorized to be registered by users or businesses that actually residein those regions. In that case, the geographical restrictions of anygTLDs (if present) can be analyzed in view of the user's location todetermine whether the geographically-restricted gTLDs should be removedor filtered from the candidate domain name list.

Additionally, in step 2208, the candidate domain names can be analyzedto determine whether they present the risk of being subject to homographattacks. Those domain names can then be filtered from the candidatedomain name list. This may be achieved using a number of differenttechniques. In one example, domain names may be disallowed and filteredif they include mixed scripts (e.g. combination of Cyrillic and Latin).

At the completion of steps 2204, 2206, and 2208, a filtered set ofcandidate domain names is generated in step 2210 and can be presented tothe user for selection and registration.

Any steps included in the embodiments illustrated in the Figures are notlimited to their respective illustrated embodiments, and may be combinedin several different orders and modified within multiple other disclosedembodiments. Likewise, the method steps disclosed herein may beaccomplished by a software module executed on a server and/or clientconfigured to accomplish that method step.

Other embodiments and uses of the above inventions will be apparent tothose having ordinary skill in the art upon consideration of thespecification and practice of the inventions disclosed herein. Thespecification and examples given should be considered exemplary only,and it is contemplated that the appended claims will cover any othersuch embodiments or modifications as fall within the true scope of theinventions.

The Abstract accompanying this specification is provided to enable theUnited States Patent and Trademark Office and the public generally todetermine quickly from a cursory inspection the nature and gist of thetechnical disclosure and in no way intended for defining, determining,or limiting the present inventions or any of its embodiments.

The inventions claimed are:
 1. A method, comprising: receiving, by oneor more computer servers via a communications network, a query includingat least one keyword, the query being submitted by a user via a clientdevice; identifying, by the one or more computer servers, a businesscategory associated with the user; accessing, by the one or morecomputer servers, a data base storing a plurality of top level domainname rankings to identify a first ranking of top level domain names forthe business category; generating, by the one or more computer servers,a package of candidate domain names relevant to the query, the packageof candidate domain names including a candidate domain name for each toplevel domain name in the first ranking of top level domain names; anddisplaying, by the one or more computer servers, the package ofcandidate domain names relevant to the query for selection andregistration by the user.